1
2
Kolejny
Nie.
JSON to tylko dane, a jeśli dołączysz komentarz, będą to również dane.
Możesz mieć wyznaczony element danych o nazwie „_comment” (lub coś takiego), który powinien być ignorowany przez aplikacje korzystające z danych JSON.
Prawdopodobnie lepiej byłoby mieć komentarz w procesach, które generują / odbierają JSON, ponieważ mają oni wiedzieć z góry, jakie będą dane JSON, a przynajmniej ich strukturę.
Ale jeśli zdecydujesz się:
{
"_comment": "tekst komentarza jest tutaj ...",
"glosariusz": {
"tytuł": "przykładowy słownik",
"GlossDiv": {
"tytuł": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standardowy uogólniony język znaczników",
"Akronim": "SGML",
„Skrót”: „ISO 8879: 1986”,
"GlossDef": {
"para": "Język meta-znaczników używany do tworzenia języków znaczników, takich jak DocBook.",
„GlossSeeAlso”: [„GML”, „XML”]
},
„GlossSee”: „znaczniki”
}
}
}
}
}
|
Nie, komentarze w postaci //… lub / *… * / nie są dozwolone w JSON. Ta odpowiedź opiera się na:
https://www.json.org
RFC 4627:
Typ nośnika application / json for JavaScript Object Notation (JSON)
RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format (zastępuje RFCs 4627, 7158, 7159)
|
Uwzględnij komentarze, jeśli chcesz; usuń je za pomocą minifier przed analizowaniem lub transmisją.
Właśnie wydałem JSON.minify (), która usuwa komentarze i spacje z bloku JSON i sprawia, że jest to poprawny JSON, który można przeanalizować. Możesz więc używać go tak:
JSON.parse (JSON.minify (my_str));
Kiedy to wydałem, spotkałem się z ogromnym sprzeciwem ludzi, którzy nie zgadzali się nawet z samym pomysłem, więc zdecydowałem, że napiszę obszerny wpis na blogu o tym, dlaczego komentarze mają sens w JSON. Zawiera ten znaczący komentarz twórcy JSON:
Załóżmy, że używasz formatu JSON do przechowywania plików konfiguracyjnych, do których chcesz dodać adnotacje. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON. - Douglas Crockford, 2012
Mam nadzieję, że jest to pomocne dla tych, którzy nie zgadzają się z tym, dlaczego JSON.minify () może być przydatne.
|
Komentarze zostały usunięte z formatu JSON zgodnie z projektem.
Usunąłem komentarze z JSON, ponieważ widziałem, że ludzie używali ich do przechowywania dyrektyw analizujących, co mogłoby zniszczyć interoperacyjność. Wiem, że brak komentarzy sprawia, że niektórzy ludzie są smutni, ale nie powinien.
Załóżmy, że używasz formatu JSON do przechowywania plików konfiguracyjnych, do których chcesz dodać adnotacje. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON.
Źródło: publiczne oświadczenie Douglasa Crockforda w G +
|
JSON nie obsługuje komentarzy. Nie było również przeznaczone do użycia w plikach konfiguracyjnych, w których potrzebne byłyby komentarze.
Hjson to format pliku konfiguracyjnego dla ludzi. Zrelaksowana składnia, mniej błędów, więcej komentarzy.
Zobacz hjson.github.io dla bibliotek JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ i C #.
|
WYŁĄCZENIE ODPOWIEDZIALNOŚCI: GWARANCJA JEST NIEWAŻNA
Jak już wspomniano, ten hack wykorzystuje implementację specyfikacji. Nie wszystkie parsery JSON zrozumieją ten rodzaj JSON. W szczególności parsery przesyłania strumieniowego będą się dławić.
To ciekawa ciekawostka, ale naprawdę nie powinieneś jej używać do niczego. Poniżej znajduje się oryginalna odpowiedź.
Znalazłem mały hack, który pozwala na umieszczanie komentarzy w pliku JSON, który nie wpłynie na analizę ani nie zmieni w żaden sposób reprezentowanych danych.
Wygląda na to, że deklarując literał obiektu, można określić dwie wartości tym samym kluczem, a pierwszeństwo ma ta ostatnia. Wierz lub nie, ale okazuje się, że parsery JSON działają w ten sam sposób. Możemy więc użyć tego do stworzenia komentarzy w źródłowym JSON, które nie będą obecne w przeanalizowanej reprezentacji obiektu.
({a: 1, a: 2});
// => Object {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Jeśli zastosujemy tę technikę, Twój skomentowany plik JSON może wyglądać następująco:
{
"api_host": "Nazwa hosta twojego serwera API. Możesz również określić port.",
"api_host": "hodorhodor.com",
"retry_interval": "Odstęp w sekundach między ponawianiem nieudanych wywołań API",
"retry_interval": 10,
"auth_token": "Token uwierzytelniający. Jest dostępny w twoim pulpicie programisty w 'Ustawieniach'",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"ulubione_numery": "Tablica zawierająca moje ulubione liczby wszech czasów",
"ulubione_numery": [19, 13, 53]
}
Powyższy kod jest prawidłowym kodem JSON. Jeśli go przeanalizujesz, otrzymasz taki obiekt:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"ulubione_numery": [19,13,53]
}
Co oznacza, że nie ma śladu komentarzy i nie będą miały dziwnych skutków ubocznych.
Miłego hakowania!
|
Rozważ użycie YAML. To prawie nadzbiór JSON (praktycznie wszystkie poprawne JSON to prawidłowe YAML) i pozwala na komentarze.
|
Nie możesz. Przynajmniej takie jest moje doświadczenie z szybkiego spojrzenia na json.org.
JSON ma swoją składnięwizualizowane na tej stronie. Nie ma żadnej notatki o komentarzach.
|
Komentarze nie są oficjalnym standardem, chociaż niektóre parsery obsługują komentarze w stylu C ++. Jednym z nich jest JsonCpp. W przykładach jest ten:
// Opcje konfiguracji
{
// Domyślne kodowanie tekstu
"encoding": "UTF-8",
// Wtyczki ładowane podczas uruchamiania
"wtyczki": [
"pyton",
"c ++",
"rubin"
],
// Rozmiar wcięcia tabulatora
"indent": {"length": 3, "use_space": true}
}
jsonlint nie sprawdza tego. Komentarze są więc rozszerzeniem specyficznym dla parsera, a nie standardem.
Kolejnym parserem jest JSON5.
Alternatywa dla JSON TOML.
Kolejną alternatywą jest jsonc.
Najnowsza wersja nlohmann / json ma opcjonalną obsługę ignorowania komentarzy podczas analizowania.
|
Zamiast tego powinieneś napisać schemat JSON. Schemat JSON jest obecnie proponowaną internetową specyfikacją roboczą. Oprócz dokumentacji schemat może być również używany do sprawdzania poprawności danych JSON.
Przykład:
{
"description": "Osoba",
"typ": "obiekt",
"nieruchomości":
{
"Nazwa":
{
"type": "string"
},
"wiek":
{
"type": "integer",
„maksymalna”: 125
}
}
}
Dokumentację można dostarczyć za pomocą atrybutu schematu opisu.
|
Jeśli używasz Jacksona jako parsera JSON, możesz go włączyć, aby zezwalał na komentarze:
ObjectMapper mapper = nowy ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Następnie możesz mieć takie komentarze:
{
klucz: "wartość" // Komentarz
}
Możesz także mieć komentarze zaczynające się od #, ustawiając:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, prawda);
Ale generalnie (jak odpowiedział wcześniej) specyfikacja nie pozwala na komentarze.
|
Oto co znalazłem w dokumentacji Google Firebase, która pozwala na umieszczanie komentarzy w JSON:
{
"//": "Niektóre przeglądarki używają tego do włączania powiadomień push.",
"//": "To jest to samo dla wszystkich projektów, to nie jest identyfikator nadawcy twojego projektu",
"gcm_sender_id": "1234567890"
}
|
NIE. JSON służył do obsługi komentarzy, ale zostały one nadużyte i usunięte ze standardu.
Od twórcy JSON:
Usunąłem komentarze z JSON, ponieważ widziałem, że ludzie używali ich do przechowywania dyrektyw analizujących, co mogłoby zniszczyć interoperacyjność. Wiem, że brak komentarzy sprawia, że niektórzy ludzie są smutni, ale nie powinien. - Douglas Crockford, 2012
Oficjalna strona JSON znajduje się pod adresem JSON.org. JSON jest zdefiniowany jako standard przez ECMA International. Zawsze istnieje procedura składania petycji o zmianę standardów. Jest mało prawdopodobne, aby adnotacje zostały dodane do standardu JSON z kilku powodów.
JSON z założenia jest alternatywą dla XML-a, którą można łatwo odtworzyć (przeanalizowaną przez człowieka). Jest uproszczony nawet do tego stopnia, że adnotacje są zbędne. Nie jest to nawet język znaczników. Celem jest stabilność i interoperacyjność.
Każdy, kto rozumie relację „ma” w orientacji obiektowej, może zrozumieć każdą strukturę JSON - o to właśnie chodzi. Jest to po prostu skierowany acykliczny wykres (DAG) ze znacznikami węzłów (pary klucz / wartość), który jest niemal uniwersalną strukturą danych.
Jedyną wymaganą adnotacją może być „// To są tagi DAG”. Nazwy kluczy mogą być tak pouczające, jak jest to wymagane, pozwalając na dowolną aranżację semantyczną.
Każda platforma może analizować JSON za pomocą zaledwie kilku wierszy kodu. XML wymaga złożonych bibliotek obiektowych, które nie działają na wielu platformach.
Adnotacje po prostu sprawią, że JSON będzie mniej interoperacyjny. Po prostu nie ma nic więcej do dodania, chyba że naprawdę potrzebujesz języka znaczników (XML) i nie przejmuj się, czy utrwalone dane można łatwo przeanalizować.
ALE, jak zauważył również twórca JSON, zawsze istniała obsługa potoku JS dla komentarzy:
Śmiało i wstaw wszystkie komentarze, które lubisz.
Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON. - Douglas Crockford, 2012
|
Jeśli twój plik tekstowy, który jest ciągiem JSON, będzie czytany przez jakiś program, jak trudno byłoby usunąć komentarze w stylu C lub C ++ przed jego użyciem?
Odpowiedź: Byłby to jeden liniowiec. Jeśli to zrobisz, pliki JSON mogą zostać użyte jako pliki konfiguracyjne.
|
Jeśli używasz biblioteki Newtonsoft.Json z ASP.NET do odczytu / deserializacji, możesz użyć komentarzy w zawartości JSON:
// "nazwa": "ciąg"
// "id": int
lub
/* To jest
przykład komentarza * /
PS: Komentarze jednowierszowe są obsługiwane tylko z wersjami 6+ Newtonsoft Json.
Dodatkowa uwaga dla osób, które nie potrafią myśleć nieszablonowo: używam formatu JSON do podstawowych ustawień w utworzonej przeze mnie aplikacji internetowej ASP.NET. Czytam plik, konwertuję go na obiekt ustawień za pomocą biblioteki Newtonsoft i używam w razie potrzeby.
Wolę pisać komentarze na temat każdego indywidualnego ustawienia w samym pliku JSON i naprawdę nie obchodzi mnie integralność formatu JSON, o ile biblioteka, której używam, jest z nim w porządku.
Myślę, że jest to „łatwiejszy w użyciu / zrozumieniu” sposób niż tworzenie osobnego pliku „settings.README” i wyjaśnianie ustawień w nim zawartych.
Jeśli masz problem z tego rodzaju użyciem; przepraszam, dżin wyszedł z lampy. Ludzie znaleźliby inne zastosowaniaJSON i nic nie możesz na to poradzić.
|
Ideą JSON jest zapewnienie prostej wymiany danych między aplikacjami. Są one zazwyczaj oparte na Internecie, a ich językiem jest JavaScript.
Tak naprawdę nie zezwala na komentarze jako takie, jednak przekazywanie komentarza jako jednej z par nazwa / wartość w danych z pewnością by działało, chociaż te dane oczywiście musiałyby zostać zignorowane lub specjalnie obsługiwane przez kod analizujący.
To powiedziawszy, nie jest zamiarem, aby plik JSON zawierał komentarze w tradycyjnym sensie. Powinny to być tylko dane.
Zajrzyj na stronę JSON, aby uzyskać więcej informacji.
|
JSON nie obsługuje komentarzy natywnie, ale możesz stworzyć własny dekoder lub przynajmniej preprocesor, aby usunąć komentarze, to jest całkowicie w porządku (o ile po prostu ignorujesz komentarze i nie używasz ich do wskazywania, jak aplikacja powinna przetwarzać dane JSON ).
JSON nie ma komentarzy. Koder JSON NIE MOŻE wyprowadzać komentarzy.
Dekoder JSON MOŻE akceptować i ignorować komentarze.
Komentarze nigdy nie powinny być używane do przekazywania niczego znaczącego. To jest
do czego służy JSON.
Por .: Douglas Crockford, autor specyfikacji JSON.
|
Właśnie napotykam to w przypadku plików konfiguracyjnych. Nie chcę używać XML (gadatliwy, graficzny, brzydki, trudny do odczytania) lub formatu "ini" (bez hierarchii, bez prawdziwego standardu itp.) Lub formatu "Właściwości" Javy (jak .ini).
JSON może zrobić wszystko, co może, ale jest o wiele mniej rozwlekły i bardziej czytelny dla człowieka - a parsery są łatwe i wszechobecne w wielu językach. To tylko drzewo danych. Ale komentarze poza pasmem są często konieczne do udokumentowania „domyślnych” konfiguracji i tym podobnych. Konfiguracje nigdy nie mają być „pełnymi dokumentami”, ale drzewami zapisanych danych, które w razie potrzeby mogą być czytelne dla człowieka.
Myślę, że można by użyć "#": "komentarz", dla "prawidłowego" JSON.
|
To zależy od Twojej biblioteki JSON. Json.NET obsługuje komentarze w stylu JavaScript, / * commment * /.
Zobacz inne pytanie dotyczące przepełnienia stosu.
|
JSON ma wiele sensu w przypadku plików konfiguracyjnych i innych zastosowań lokalnych, ponieważ jest wszechobecny i ponieważ jest znacznie prostszy niż XML.
Jeśli ludzie mają silne powody, by nie umieszczać komentarzy w formacie JSON podczas przesyłania danych (niezależnie od tego, czy są one prawidłowe, czy nie), prawdopodobnie można podzielić JSON na dwie części:
JSON-COM: JSON w sieci lub reguły, które mają zastosowanie podczas przesyłania danych JSON.
JSON-DOC: dokument JSON lub JSON w plikach lub lokalnie. Reguły definiujące prawidłowy dokument JSON.
JSON-DOC zezwoli na komentarze i mogą istnieć inne drobne różnice, takie jak obsługa białych znaków. Parsery można łatwo konwertować z jednej specyfikacji na drugą.
W odniesieniu do uwagi Douglasa Crockforda w tej sprawie (powołana przez @Artur Czajka)
Załóżmy, że używasz formatu JSON do przechowywania plików konfiguracyjnych, do których chcesz dodać adnotacje. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON.
Mówimy o ogólnym problemie z plikiem konfiguracyjnym (między językami / platformami), a on odpowiada za pomocą specjalnego narzędzia JS!
Oczywiście minify specyficzne dla JSON można zaimplementować w dowolnym języku,
ale ujednolicić to, aby stało się wszechobecne we wszystkich parserach we wszystkich językach i na wszystkich platformach, aby ludzie przestali marnować czas na brak tej funkcji, ponieważ mają dobre przykłady użycia, szukają problemu na forach internetowych i zachęcają ludzi do mówienia im, że to zły pomysł lub sugerując, że można łatwo zaimplementować usuwanie komentarzy z plików tekstowych.
Drugą kwestią jest interoperacyjność. Załóżmy, że masz bibliotekę, API lub dowolny rodzaj podsystemu, z którym są powiązane jakieś pliki konfiguracyjne lub pliki danych. A ten podsystem jest
być dostępne w różnych językach. Następnie mówisz ludziom: tak przy okazji
nie zapomnij usunąć komentarzy z plików JSON przed przekazaniem ich do parsera!
|
Jeśli używasz JSON5, możesz dołączyć komentarze.
JSON5 to proponowane rozszerzenie JSON, które ma na celu ułatwienie ludziom pisania i obsługi ręcznie. Czyni to poprzez dodanie kilku minimalnych funkcji składni bezpośrednio z ECMAScript 5.
|
Zestaw narzędzi Dojo Toolkit JavaScript (przynajmniej od wersji 1.4) umożliwia umieszczanie komentarzy w pliku JSON. Komentarze mogą mieć format / * * /. Dojo Toolkit zużywa JSON poprzez wywołanie dojo.xhrGet ().
Inne zestawy narzędzi JavaScript mogą działać podobnie.
Może to być pomocne podczas eksperymentowania z alternatywnymi strukturami danych (lub nawet listami danych) przed wybraniem ostatecznej opcji.
|
JSON nie jest protokołem ramkowym. Jest to format wolny od języków. Dlatego format komentarza nie jest zdefiniowany dla JSON.
Jak sugerowało wiele osób, istnieją pewne sztuczki, na przykład zduplikowane klucze lub określony klucz _comment, którego możesz użyć. To zależy od Ciebie.
|
Możesz mieć komentarze w formacie JSONP, ale nie w czystym formacie JSON. Właśnie spędziłem godzinę, próbując zmusić mój program do pracy z tym przykładem z Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Jeśli podążasz za linkiem, zobaczysz
? (/ * AAPLhistoryczne dane OHLC z Google Finance API * /
[
/ * Maj 2006 * /
[1147651200000,67,79],
[1147737600000,64,98],
...
[1368057600000 456,77],
[1368144000000, 452,97]
]);
Ponieważ miałem podobny plik w moim folderze lokalnym, nie było problemów z polityką tego samego pochodzenia, więc zdecydowałem się użyć czystego JSON ... i oczywiście $ .getJSON po cichu zawodziło z powodu komentarzy.
W końcu właśnie wysłałem ręczne żądanie HTTP na powyższy adres i zdałem sobie sprawę, że typ zawartości to text / javascript, ponieważ, cóż, JSONP zwraca czysty JavaScript. W takim przypadku komentarze są dozwolone. Ale moja aplikacja zwróciła application / json typu zawartości, więc musiałem usunąć komentarze.
|
To jest pytanie typu „czy potrafisz”. A oto odpowiedź „tak”.
Nie, nie należy używać zduplikowanych elementów składowych obiektu do umieszczania danych kanału bocznego w kodowaniu JSON. (Zobacz „Nazwy w obiekcie POWINNY być unikalne” w specyfikacji RFC).
I tak, możesz wstawiać komentarze wokół JSON, które możesz przeanalizować.
Ale jeśli chcesz wstawić i wyodrębnić dowolne dane kanału bocznego do prawidłowego formatu JSON, oto odpowiedź. Korzystamy z nieunikalnej reprezentacji danych w kodowaniu JSON. Jest to dozwolone * w sekcji drugiej dokumentu RFC pod „białą spacją przed lub po którymkolwiek z sześciu znaków strukturalnych”.
* Dokument RFC stwierdza tylko, że „białe znaki są dozwolone przed lub po dowolnym z sześciu znaków strukturalnych”, nie wspominając wprost o łańcuchach, liczbach, „fałszu”, „prawda” i „null”. To pominięcie jest ignorowane we WSZYSTKICH implementacjach.
Najpierw kanonizuj swój JSON, minimalizując go:
$ jsonMin = json_encode (json_decode ($ json));
Następnie zakoduj swój komentarz binarnie:
$ hex = unpack ('H *', $ komentarz);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Następnie steguj swój plik binarny:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Oto wynik:
$ jsonWithComment = $ steg. $ jsonMin;
|
Zastrzeżenie: to jest głupie
W rzeczywistości istnieje sposób na dodawanie komentarzy i pozostanie w specyfikacji (nie jest potrzebny dodatkowy parser). Nie spowoduje to jednak komentarzy czytelnych dla człowieka bez jakiejkolwiek analizy.
Możesz nadużywać następujących rzeczy:
Niewielkie spacje są dozwolone przed lub po dowolnym tokenie.
Biała spacja to dowolna sekwencja jednego lub więcej poniższych kodów
punkty: tabulacja znaków (U + 0009), przesunięcie wiersza (U + 000A), karetka
return (U + 000D) i spacja (U + 0020).
W niecodzienny sposób możesz to wykorzystać, aby dodać komentarz. Na przykład: rozpocznij i zakończ swój komentarz kartą. Zakoduj komentarz w base3 i użyj innych białych znaków do ich przedstawienia. Na przykład.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(witaj, podstawa trzy w ASCII) Ale zamiast 0 użyj spacji, dla 1 użyj znaku nowego wiersza, a dla 2 użyj powrotu karetki.
To po prostu pozostawi wiele nieczytelnych białych znaków (chyba że stworzysz wtyczkę IDE do kodowania / dekodowania w locie).
Nigdy nawet tego nie próbowałem, z oczywistych powodów i ty też nie powinieneś.
|
JSON nie zezwala na komentarze jako takie. Rozumowanie jest całkowicie głupie, ponieważ możesz użyć samego JSON do tworzenia komentarzy, co całkowicie eliminuje rozumowanie i ładuje przestrzeń danych parsera bez żadnego dobrego powodu dla dokładnie tego samego wyniku i potencjalnych problemów, takich jak: plik z komentarzami.
Jeśli spróbujesz wstawić komentarze (używając na przykład // lub / * * / lub #), niektóre parsery zawiodą, ponieważ nie jest to ściśle
w specyfikacji JSON. Więc nigdy nie powinieneś tego robić.
Tutaj na przykład, gdzie mój system obróbki obrazu zapisał notacje obrazu i niektóre podstawowe sformatowane (komentarz) informacje dotyczące ich (na dole):
{
„Notations”: [
{
"anchorX": 333,
"kotwicaY": 265,
"areaMode": "Elipsa",
"extX": 356,
"zakresY": 294,
„krycie”: 0,5,
"text": "Eliptyczny obszar na górze",
"tekstX": 333,
"tekstY": 265,
"title": "Notacja 1"
},
{
"anchorX": 87,
"kotwicaY": 385,
"areaMode": "Rectangle",
"extX": 109,
„zakresY”: 412,
„krycie”: 0,5,
"text": "Prosty obszar \ inny niż dolny",
"tekstX": 98,
"tekstY": 385,
"title": "Notacja 2"
},
{
"anchorX": 69,
"kotwicaY": 104,
"areaMode": "Polygon",
"extX": 102,
„zakresY”: 136,
„krycie”: 0,5,
"pointList": [
{
„i”: 0,
„x”: 83,
„y”: 104
},
{
„i”: 1,
"x": 69,
„y”: 136
},
{
„i”: 2,
„x”: 102,
„y”: 132
},
{
„i”: 3,
„x”: 83,
„y”: 104
}
],
"text": "Prosty wielokąt",
"tekstX": 85,
"tekstY": 104,
"title": "Notacja 3"
}
],
„imageXW”: 512,
„imageYW”: 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Dane notacji obrazu JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Te dane zawierają notacje obrazu i powiązany obszar",
"c05": "informacja o wyborze, która zapewnia środki dla",
"c06": "galeria obrazów do wyświetlania notacji z eliptycznym,",
"c07": "prostokątne, wielokątne lub odręczne oznaczenia obszaru",
"c08": "nad obrazem wyświetlanym odwiedzającemu galerię.",
"c09": "",
"c10": "Wszystkie pozycje X i Y są widoczne na obrazieprzestrzeń. Obraz",
"c11": "rozdzielczość jest podana jako imageXW i imageYW, co",
"c12": "używasz do skalowania obszarów notacji do ich właściwych",
"c13": "lokalizacje i rozmiary wyświetlania obrazu,",
"c14": "niezależnie od skali.",
"c15": "",
"c16": "W przypadku elips kotwica jest środkiem elipsy,",
"c17": ", a zakresy to odpowiednio promienie X i Y.",
"c18": "",
"c19": "W przypadku prostokątów kotwica znajduje się w lewym górnym rogu, a",
"c20": "zakresy znajdują się w prawym dolnym rogu.",
"c21": "",
"c22": "W przypadku trybów obszaru Odręczne i Wielobok punktLista",
"c23": "zawiera szereg ponumerowanych punktów XY. Jeśli obszar",
"c24": "jest zamknięte, ostatni punkt będzie taki sam jak",
"c25": "po pierwsze, więc jedyne czym musisz się zająć to rysowanie",
"c26": "linie między punktami na liście. Zakotwiczenie i zasięg",
"c27": "są ustawione w lewym górnym rogu i prawym dolnym rogu wskazanych",
"c28": "region i może być używany jako uproszczony prostokąt",
"c29": "wykryj położenie kursora myszy nad tymi typami",
"c30": "obszarów.",
"c31": "",
"c32": "Pozycje textx i texty zapewniają podstawowe pozycjonowanie",
"c33": "informacje pomocne w zlokalizowaniu informacji tekstowych",
"c34": "w rozsądnej lokalizacji związanej z obszarem",
"c35": "wskazanie.",
"c36": "",
"c37": "Krycie to wartość z przedziału od 0 do 1, gdzie .5 oznacza",
"c38": "tło nieprzezroczyste w 50%, a tło 1.0 reprezentuje całkowicie nieprzezroczyste",
"c39": "tło. Zalecamy rysowanie regionów",
"c40": "tylko wtedy, gdy użytkownik najedzie kursorem na obraz,",
"c41": "i że tekst powiązany z regionami jest narysowany",
"c42": "tylko wtedy, gdy użytkownik najedzie kursorem na wskazane",
„c43”: „region”.
}
}
|
W naszym projekcie używamy strip-json-comments. Obsługuje coś takiego:
/ *
* Opis
* /
{
// tęcze
„jednorożec”: / * ❤ * / „ciasto”
}
Po prostu zainstaluj npm - zapisz strip-json-comments, aby zainstalować i używaj go tak, jak:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * tęcze * / "jednorożec": "ciasto"}';
JSON.parse (strip_json_comments (json));
// => {jednorożec: 'ciasto'}
|
W moim przypadku potrzebuję komentarzy do celów debugowania tuż przed wyjściem struktury JSON. Postanowiłem więc użyć informacji debugowania w nagłówku HTTP, aby uniknąć zepsucia klienta:
header („My-Json-Comment: Tak, wiem, że to obejście ;-)”);
|
Aby wyciąć element JSON na części, dodaję wiersze „fikcyjny komentarz”:
{
"#############################" : "Część 1",
"dane1": "wartość1",
"dane2": "wartość2",
"#############################" : "Część 2",
"dane4": "wartość3",
"dane3": "wartość4"
}
|
1
2
Kolejny
Bardzo aktywne pytanie. Zdobądź 10 punktów reputacji, aby odpowiedzieć na to pytanie. Wymóg dotyczący reputacji pomaga chronić to pytanie przed spamem i brakiem odpowiedzi.
Nie szukasz odpowiedzi? Przeglądaj inne pytania oznaczone tagami json komentarze lub zadaj własne pytanie.